1. Field of the Invention
The invention is related to mobile communications systems. More specifically it relates to local IP mobility from mobile communications on the internet protocol (IPv6) or similar protocols.
2. Description of the Related Art
The invention is described for the example of the Internet Protocol version 6 (IPv6). It is, however, also applicable to other protocols defining equivalent entities corresponding to the described entities of IPv6.
When an IPv6 mobile node (MN) moves from a serving access router (AR) to another AR on a different IP link, the mobile node needs to configure new IP address(es) based on the IP prefix(es) advertised by the new AR. The change of the serving AR means that a new IP connectivity has to be re-established, and therefore that active IP sessions will be lost.
One approach to keep the existing active IP sessions alive is the Mobile IPv6 (MIPv6) protocol, RFC3775 (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, RFC3775, June 2004).
In MIPv6, each MN has configured a home IP address (HoA), which is used to identify itself independently of its topological location in the Internet. The MN also configures a care-of-address (CoA), which is topologically related to the actual location of the MN. Whenever a MN performs a handover, a new CoA is configured and announced to the home agent (HA), which tunnels the packets to the MN.
Another approach to keep the existing active IP sessions alive is to configure a local set of ARs to advertise the same set of IP prefixes, so that the MN can keep using the IP addresses that have been configured at the old AR. This approach is called network-based localized mobility management (NetLMM, a description of the NetLMM framework can be found at: http://www.ieff.org/html.charters/netlmm-charter.html), since the MN is not actively involved in mobility management functions.
In contrast to NetLMM, MIPv6 can be categorized as host-based mobility management. Detailed information about the problems with existing host-based mobility management can be found in J. Kempf et. al. (“Problem Statement for IP Local Mobility”, draft-kempf-netlmm-nohost-ps-00.txt, June 2005), it also describes an architecture for a possible localized mobility management approach.
The NetLMM protocol proposed by Giaretta et al. (G. Giaretta et al., “Network-based localized mobility management (NETLMM) with distributed anchor routers”, draft-giaretta-netlmm-protocol-00.txt), 2005 can be used to handle IP mobility within a localized mobility management domain. The edge of a domain is made up of Access Routers (ARs) and Border Gateways (BGs) 106, as illustrated in FIG. 1. An AR 102 can manage one or more IP links (i.e. layer 2 access networks), each one univocally associated with at least an IPv6 prefix. It represents the first IP router encountered by the mobile node 100 on the way to the destination. The BGs 106 are used to interconnect the domain with external networks, like the Internet. There are no constraints on the internal topology of a domain. As long as the mobile node 100 remains within the same domain, it can keep on using the same IP address even if it happens to change the AR it is attached to.
The AR 102 on the link where an MN powers on will be the Home Access Router (HAR) for that MN 100. The IP address of the MN 100 will be based on the prefix advertised by its HAR 102. As long as the MN 100 is on the same link as its HAR 102, packets can be normally routed (i.e. no tunnelling) to and from the MN 100, since the MN's IP address is topologically correct.
If an MN moves away from its HAR, it can keep using the same IP address, despite the fact that that address is now topologically incorrect. To allow this IP tunnelling is used to direct packets between the HAR and the Visiting AR (VAR).
The problem with the previously described prior art is that tunnels are needed if the MN moves away from its HAR (this is the AR where the MN powers on). Tunnels are inefficient for a number of reasons:
Workload increase at the tunnel endpoints: Each packet through the tunnel needs to be encapsulated and decapsulated, and this requires processing at the endpoints.
Increased Bandwidth Consumption: Because of the extra header needed for tunnelling, 40 additional bytes are needed for each packet (when using IPv6). For small packets like voice packets, this is a very high overhead.
Increased packet end-to-end delay: This is a direct result of the two reasons explained above.
Due to these drawbacks of tunnels, the goal of this invention is to avoid or limit the use of tunnels, while maintaining all functionalities of the prior art.
“Always on” devices can be particularly disadvantageous when used in Giaretta's NetLMM, namely if that device powers on at a place where it normally does not reside, it may occur that that device will always need a tunnel for the rest of its on period.